Software Defined Radio (SDR) works much like desktop computing, where a single hardware platform can carry out many functions based on the software applications loaded. SDR uses software to perform radio-signal processing functions instead of using resistors, capacitors, feedback loops, or application-specific integrated circuits. Frequency tuning, filtering, synchronization, encoding and modulation are performed in software on high-speed reprogrammable devices such as digital signal processors (DSP), field programmable gate array (FPGA), or general purpose processors (GPP). RE components may still be needed for generation of high frequencies or for signal amplifications and radiation.
At the center of SDR technology is the software architecture on which the radios must be built and communication protocols implemented. Many proprietary architectures exist, but to ensure portability and interoperability of the protocols on the different radios, an open architecture was developed. The Software Communications Architecture (SCA) is a set of specifications describing the interaction between the different software and hardware components of a radio and providing software commands for their control. The SCA has been developed by the U.S. Department of Defense Joint Tactical Radio System (JTRS) project. The SCA is an open architecture framework that specifies how hardware and software components are to interoperate so that different manufacturers and developers can readily integrate the respective components into a single device.
So, SDRs can be typically implemented with relatively standard processor and hardware components. One particular class of software radio is the Joint Tactical Radio (JTR), which includes relatively standard radio and processing hardware along with any appropriate waveform software modules to implement the communication waveforms a radio will use. JTR radios also use operating system software that conforms with the SCA specification (see www.jtrs.saalt.mil), which is hereby incorporated by reference in its entirety.
The JTRS SCA defines a set of interfaces and protocols, often based on the Common Object Request Broker Architecture (CORBA), for implementing an SDR. In part, JTRS and its SCA are used with a family of software re-programmable radios. As such, the SCA is a specific set of rules, methods, and design criteria for implementing software re-programmable digital radios.
The JTRS SCA specification is published by the JTRS Joint Program Office (JPO). The JTRS SCA has been structured to provide for portability of applications software between different JTRS SCA implementations, leverage commercial standards to reduce development cost, reduce development time of new waveforms through the ability to reuse design modules, and build on evolving commercial frameworks and architectures.
The JTRS SCA is not a system specification, as it is intended to be implementation independent, but a set of rules that constrain the design of systems to achieve desired JTRS objectives. The software framework of the JTRS SCA defines the Operating Environment (OE) and specifies the services and interfaces that applications use from that environment. The SCA OE comprises a Core Framework (CF), a CORBA middleware, and an Operating System (OS) based on the Portable Operating System Interface (POSIX) with associated board support packages. The JTRS SCA also provides a building block structure (defined in the API Supplement) for defining application programming interfaces (APIs) between application software components.
The JTRS SCA Core Framework (CF) is an architectural concept defining the essential, “core” set of open software Interfaces and Profiles that provide for the deployment, management, interconnection, and intercommunication of software application components in embedded, distributed-computing communication systems. Interfaces may be defined in the JTRS SCA Specification. However, developers may implement some of them, some may be implemented by non-core applications (i.e., waveforms, etc.), and some may be implemented by hardware device providers.
The JTRS approach includes provisions to install/uninstall a waveform application to add or alter a feature set. However, the JTRS radio architecture has no provisions to control installation or access to features and/or waveforms. The current approach does not address modifications of a feature set within a waveform, control of waveform or features to specific customers or specific orders, and/or control of features requiring royalties.